1. The Field of the Invention
This invention relates to systems, methods, and computer program products for relaying messages such as Simple Object Access Protocol (SOAP) messages between two or more computers using custom security tokens.
2. Background and Relevant Art
Computerized systems provide many advantages toward people's ability to perform tasks. To enable these advantages, computer systems often come equipped with (or are expandable to include) multiple hardware devices that can store or read data, or enable a software program to perform a specific action on data. Such devices can include, for example, a hard drive, a Compact Disc (i.e., CDROM, CDRW, etc.), a Universal Serial Bus (USB) device (e.g., a printer, a scanner, etc.), and so on. Present computer systems also commonly have installed thereon multiple software (or “application”) programs such as a word processing program, a spreadsheet program, an imaging program, and an electronic mail program, which instruct the devices to perform specific actions on the data.
Accordingly, a user will often implement multiple devices and multiple application programs on a computer system so that the user can have many tools available for performing various tasks. There are, however, many limits to this sort of approach. For example, cost issues become apparent since applications and additional devices can each be very expensive, depending on the types of tasks the user wishes to perform.
Furthermore, computer systems typically have a finite number of “expansion ports” to add new devices, and have a finite amount of storage space on which a user can install additional application programs. Of course, these limitations are exacerbated by the fact that multiple devices and application programs often create significant resource (e.g., CPU cycles, random access memory, etc.) drains on a computer system. Accordingly, it is well known that not all of a user's task requirements can be solved adequately simply by adding an additional device or an application program.
Presently, some solutions have been designed to help accommodate these sorts of limitations. For example, computer systems on a Local or Wide Area Network (LAN, or WAN) often have access to network resources that can include use of a network storage device, or processing resources on another network computer. These solutions, however, generally require that the computer the user wishes to use on the respective network communicate using a specific communication protocol (whether an application-specific, an operating system-specific, or a network communication protocol, etc.). In addition, these methods do not provide relief to computer systems that have many devices or applications installed on the machine.
Other solutions, however, are geared more toward handling specific tasks needed by an application program on a computer system. Some solutions, such as, for example, the Simple Object Access Protocol (SOAP), allow users to reduce the resource requirements otherwise needed to handle the respective application requests. Generally, solutions for handling specific processing requests involve an application at one computer system sending a request for another computer system over a network to process an object (e.g., a set of instructions), rather than requiring the computer system on which the application is installed to process the instructions. The messages invoking such requests are ideal in that they are not typically limited to a specific operating system, application, or network communication protocol. In particular, since computer system applications normally send these types of messages in a markup language (e.g., Extensible Markup Language—XML), such messages can be understood by many operating systems, applications, and communication protocols.
There are, however, certain security risks when sending these types of messages. Ordinarily, when a sending computer system sends a secure message to another receiving computer system, the sending computer system implements instructions to at least partially secure the message, often through encrypting the message. The sending computer system then places the message on a network with an identifier representing the receiving computer system. In transit to the receiving computer system, the message is likely to be transferred through one or more intermediate computer systems before the receiving computer system receives the message. Often times the sending computer system will send a decryption key separately with the message. The receiving computer system can then utilize the decryption key (if received) to read the message.
One problem with this approach is that the decryption key can become separated from the message as the message travels through one or more intermediate computer systems. Intermediate computer systems might also handle the decryption key inappropriately such that it becomes corrupted in transit. Accordingly, the receiving computer system may not properly receive the decryption key, and may not be able to un-secure (decrypt) the message, and thus may not be able to read the message.
Some solutions to this problem, particularly in the case of simple object access protocol messages, involve embedding the security information into each message before securing the entire message. While this keeps security information from being detached (or separately corrupted), another problem arises in that each intermediate computer system may need to un-secure (decrypt) the entire message to find out the message destination. Once the intermediate computer system determines where the message is destined, the intermediate computer system will then re-secure (re-encrypt) the entire message and send the message to either a next intermediate computer system (that will do the same decryption/re-encrypt), or to the receiving computer system. Of course, this adds a layer of uncertainty since the sending computer system may not trust the intermediate computer system to maintain the appropriate security settings upon un-securing/re-securing (decrypting or re-encrypting) the message.
Other problems with embedding security settings in a message related to the customization of the security settings. Generally, simple object access protocol messages are secured with information that identifies the sender, and requires identification of the receiver before the receiver can un-secure (decrypt) the message. Consequently, these types of security settings cannot be configured to limit file access to the message, for example, between only certain time frames during a day. Furthermore, simply packaging the message creation software with more security setting fields does not necessarily increase message security. This is due in part since default fields can be identified by another computer system simply by utilizing the application program used to create the message.
Accordingly, systems, methods, and computer program products that relay object requests using customizable, embedded security settings would be an advantage in the art. In addition, it would be an advantage in the art to provide computer systems with an opportunity to define their own security settings, and share those security settings only with appropriate, intended recipients.